The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
1. Stream Control Transmission Protocol
SCTP is a general-purpose transport protocol for message-oriented applications that was designed by the Internet Engineering Task Force (IETF) SIGTRAN working group, which released the SCTP standard draft document in IETF Request for Comments (RFC) 2960 in October 2000. SCTP provides support for multi-homed hosts, and can be used as the transport protocol for upper-layer applications that require monitoring and detection of loss of session. The computer system hosts communicating over an SCTP transport connection are usually represented by the so-called SCTP endpoints. An SCTP endpoint is the logical sender/receiver of SCTP packets. An SCTP endpoint is associated with one or more transport addresses, and each transport address is defined by a Network Layer address, a Transport Layer protocol and a Transport Layer port number. For example, in the case of SCTP running over IP, a transport address is defined by the combination of an IP address and an SCTP port number (where SCTP is the Transport Layer protocol). According to the standard SCTP specification, each message containing user data and sent from one SCTP endpoint to another must be acknowledged by the receiving SCTP endpoint.
An SCTP association is a protocol relationship between SCTP endpoints, and is composed of the two SCTP endpoints and the protocol state information. The protocol state information includes, among other parameters, one or more verification tags, a set of transmission sequence numbers, and a set of stream sequence numbers. An SCTP association can be uniquely identified by the transport addresses used by the endpoints in the association. Two SCTP endpoints cannot have more than one SCTP association between them at any given time.
The data units transported over an SCTP transport connection are referred to as SCTP packets. If SCTP runs over Internet Protocol (IP), an SCTP packet forms the payload of an IP packet. An SCTP packet is composed of a common header and one or more chunks. The common header contains fields for a source port number, a destination port number, a verification tag, and a checksum. The source port numbers and the destination port numbers are used for the identification of an SCTP association. SCTP uses the same port concept used by Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP). The verification tag is a randomly generated value that is SCTP association-specific, and is exchanged between the SCTP endpoints at the SCTP association startup. The verification tag serves as a key that allows a receiver to verify that the SCTP packet belongs to the current SCTP association. The checksum is used for the detection of transmission errors.
A chunk is a unit of information within an SCTP packet, consisting of a chunk header and chunk-specific content. A chunk header includes a chunk type field, used to distinguish upper-layer application data chunks and different types of control chunks, chunk flag field for chunk specific flags, and a chunk length field. The chunk-specific content occupies the rest of the chunk, and is represented as a value field that contains the actual payload of the chunk. A Transmission Sequence Number (TSN) is attached to each chunk containing upper-layer application data to permit the receiving SCTP endpoint to acknowledge the receipt of the chunk and to detect duplicate deliveries. The TSN is a 32-bit sequence number maintained internally by the SCTP stack.
SCTP supports different streams of messages within one SCTP association. A message is a unit of data in a chunk sent by an upper-layer application over the SCTP association from one SCTP endpoint to another. A stream is a unidirectional logical channel established from one SCTP endpoint to another associated SCTP endpoint, within which all data messages are delivered in sequence unless out-of-order delivery is requested by the upper-layer application. A 16-bit sequence number, called the Stream Sequence Number (SSN), is associated with each stream, and is maintained internally by the SCTP stack to ensure sequenced delivery of the data messages within a given stream to the upper-layer application. One SSN is attached to each data message sent or received by the upper-layer application.
2. Path MTU Discovery
A Path Maximum Transmission Unit (PMTU) value is the maximum number of bytes of an IP datagram that can be transferred in a single unit over a specific path in an IP network. The PMTU for a particular path may vary widely as a result of congestion or other network conditions. If an IP datagram exceeds the MTU, normally it is either fragmented into smaller pieces by the network en route to its destination or dropped by the network.
Path MTU discovery (PMTUD) is a method used to intelligently discover the path maximum transmission unit (MTU) for a particular connection. The most common technique for PMTUD is described in RFC 1191. The objective is to find the MTU value for a path so that IP datagrams can be delivered without fragmentation. PMTUD is a mandatory function of SCTP that makes SCTP more adaptive to various network conditions. In SCTP the PMTU value is dynamic; changes within the routing infrastructure of the network can lead to a different path through the network, and thus to a different value for PMTU.
A common approach to implement PMTUD involves configuring hosts to mark outbound IP datagrams with a “Don't Fragment” (DF) bit in the IP header which directs routers along the path not to fragment an IP packet. For example, when a router receives a 1,500-byte IP datagram in which the DF bit is set to 1, and the route of choice is over a link having a PMTU of 512, the router cannot forward the IP datagram. Instead, the router returns to the sender an ICMP message coded to indicate that the destination is unreachable due to the need to fragment. (See RFC 1191.)
To handle the ICMP message, the SCTP sender may either reduce the size of datagrams it is sending along the path, or cease setting the DF bit in the headers of those datagrams. Clearly, the former strategy may continue to elicit ICMP messages for a while, whereas ceasing to set the DF bit authorizes the IP layer along the path to perform IP fragmentation on the datagram whenever it becomes necessary. However, fragmentation is undesirable for many reasons.
ICMP messages are unreliable, and due to the security risk they pose, ICMP is not widely enabled on routers that are coupled to the public Internet. In fact, routers of many enterprises drop all ICMP messages. This seriously hinders operation of the PMTU algorithm, resulting in upstream routers settling for a sub-optimal MTU. Additionally, the result of setting the DF bit in all IP datagrams results in numerous dropped packets, and as a result seriously affects throughput. A new technique is needed that does not involve ICMP messaging or participation from intermediary routers.